MeshPacket

A packet envelope sent/received over the mesh
only payload_variant is sent in the payload portion of the LORA packet.
The other fields are either not sent at all, or sent in the special 16 byte LORA header.

Identify if this is a delayed packet

The priority of this message for sending.
Higher priorities are sent first (when managing the transmit queue).
This field is never sent over the air, it is only used internally inside of a local device node.
API clients (either on the local node or connected directly to the node)
can set this parameter if necessary.
(values must be <= 127 to keep protobuf field to one byte in size.
Detailed background on this field:
I noticed a funny side effect of lora being so slow: Usually when making
a protocol there isn’t much need to use message priority to change the order
of transmission (because interfaces are fairly fast).
But for lora where packets can take a few seconds each, it is very important
to make sure that critical packets are sent ASAP.
In the case of meshtastic that means we want to send protocol acks as soon as possible
(to prevent unneeded retransmissions), we want routing messages to be sent next,
then messages marked as reliable and finally 'background' packets like periodic position updates.
So I bit the bullet and implemented a new (internal - not sent over the air)
field in MeshPacket called 'priority'.
And the transmission queue in the router object is now a priority queue.

Enum to identify which transport mechanism this packet arrived over

(Usually) If set, this indicates the index in the secondary_channels table that this packet was sent/received on.
If unset, packet was on the primary channel.
A particular node might know only a subset of channels in use on the mesh.
Therefore channel_index is inherently a local concept and meaningless to send between nodes.
Very briefly, while sending and receiving deep inside the device Router code, this field instead
contains the 'channel hash' instead of the index.
This 'trick' is only used while the payload_variant is an 'encrypted'.

TODO: REPLACE

TODO: REPLACE

Describe if this message is delayed

Describe if this message is delayed

TODO: REPLACE

The sending node number.
Note: Our crypto implementation uses this field as well.
See [crypto](/docs/overview/encryption) for details.

If unset treated as zero (no forwarding, send to direct neighbor nodes only)
if 1, allow hopping through one node, etc...
For our usecase real world topologies probably have a max of about 3.
This field is normally placed into a few of bits in the header.

Hop limit with which the original packet started. Sent via LoRa using three bits in the unencrypted header.
When receiving a packet, the difference between hop_start and hop_limit gives how many hops it traveled.

A unique ID for this packet.
Always 0 for no-ack packets or non broadcast packets (and therefore take zero bytes of space).
Otherwise a unique ID for this packet, useful for flooding algorithms.
ID only needs to be unique on a _per sender_ basis, and it only
needs to be unique for a few minutes (long enough to last for the length of
any ACK or the completion of a mesh broadcast flood).
Note: Our crypto implementation uses this id as well.
See [crypto](/docs/overview/encryption) for details.

Last byte of the node number of the node that should be used as the next hop in routing.
Set by the firmware internally, clients are not supposed to set this.

Indicates whether the packet was en/decrypted using PKI

The priority of this message for sending.
See MeshPacket.Priority description for more details.

The priority of this message for sending.
See MeshPacket.Priority description for more details.

Records the public key the packet was encrypted with, if applicable.

Last byte of the node number of the node that will relay/relayed this packet.
Set by the firmware internally, clients are not supposed to set this.

rssi of received packet. Only sent to phone for dispay purposes.

*Never* sent over the radio links.
Set during reception to indicate the SNR of this packet.
Used to collect statistics on current link quality.

The time this message was received by the esp32 (secs since 1970).
Note: this field is _never_ sent on the radio link itself (to save space) Times
are typically not sent over the mesh, but they will be added to any Packet
(chain of SubPacket) sent to the phone (so the phone can know exact time of reception)

The (immediate) destination for this packet

Indicates which transport mechanism this packet arrived over

Indicates which transport mechanism this packet arrived over

*Never* sent over the radio links.
Timestamp after which this packet may be sent.
Set by the firmware internally, clients are not supposed to set this.

Describes whether this packet passed via MQTT somewhere along the path it currently took.

This packet is being sent as a reliable message, we would prefer it to arrive at the destination.
We would like to receive a ack packet in response.
Broadcasts messages treat this flag specially: Since acks for broadcasts would
rapidly flood the channel, the normal ack behavior is suppressed.
Instead, the original sender listens to see if at least one node is rebroadcasting this packet (because naive flooding algorithm).
If it hears that the odds (given typical LoRa topologies) the odds are very high that every node should eventually receive the message.
So FloodingRouter.cpp generates an implicit ack which is delivered to the original sender.
If after some time we don't hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic.
Note: This flag is normally sent in a flag bit in the header when sent over the wire

TODO: REPLACE

TODO: REPLACE